Skip to main content
Version: 2.0

Experimentation Encouragement

For two decades I’ve seen engineering teams achieve incredible things, and equally, I’ve seen them get stuck. The difference? Often it boils down to psychological safety and a willingness to try – to experiment. It’s easy to pay lip service to innovation, but truly fostering a culture of experimentation requires deliberate effort. It’s about balancing risk with learning, and embracing failure as a crucial part of the process.

This isn't just fluffy team-building. It directly impacts our ability to deliver high-quality software, adapt to changing requirements, and stay ahead of the curve. Here's how to encourage experimentation within your engineering teams, moving beyond buzzwords to practical implementation.

The Problem with "Just Do It" Innovation​

We’re bombarded with messaging about innovation. “Think outside the box!” “Disrupt!” While inspiring in theory, this can be paralyzing for many engineers. The pressure to always be innovative, without a framework for trying and failing, leads to analysis paralysis or, worse, a fear of suggesting anything new at all.

I’ve seen this manifest in a few ways:

  • Over-Engineering "Experiments": Teams treat small tests like massive, months-long projects. They aim for perfection before learning if the core idea even has merit. For example, a team spent weeks perfecting a prototype for a new feature, only to discover through user testing that the core concept wasn't viable. This is a classic example of letting the methodology overshadow the work.
  • Risk Aversion: Engineers stick to tried-and-true methods, even if they’re sub-optimal, because the cost of failure (even a small one) feels too high.
  • "Not Invented Here" Syndrome: Dismissing potentially valuable ideas simply because they didn't originate within the team.

The reality is, most developers need a recipe to follow. They benefit from a structured approach to experimentation. It's not about stifling creativity; it's about channeling it effectively.

A Framework for Encouraging Safe Experiments​

Here's a three-pronged approach I’ve found successful:

1. Normalize Failure as Learning:

This isn’t just about saying “it’s okay to fail.” It's about actively celebrating learnings from failures.

  • Post-Mortem Rituals: After every significant project, hold a blameless post-mortem. Focus on what went wrong and why, not who is at fault. A simple “What Went Well, What Could Be Improved, Action Items” structure is a great start.
  • “Failure Bows”: (Use with discretion and team buy-in). Encourage engineers to openly share experiments that didn’t work, highlighting what they learned. This normalizes risk-taking.
  • Share “Near Misses”: Don’t just focus on spectacular failures. Discuss times when a potentially problematic approach was identified before causing significant issues. This demonstrates proactive risk management.

2. Implement “Spike” Solutions & Timeboxing:

“Spikes” are short, time-boxed explorations – essentially dedicated time to investigate a specific technical challenge or concept. They’re a low-risk way to test assumptions.

  • Define a Clear Goal: What question is the spike meant to answer?
  • Timebox It: Two to three days is often a good starting point. Crucially, stop when the time is up, even if the answer isn’t definitive. This prevents scope creep and forces prioritization.
  • Focus on Learning, Not Delivery: The output of a spike isn’t production-ready code; it’s data. “This approach is viable,” “This library is too complex,” “We need to revisit our assumptions.”
  • Visuals: A simple Kanban board with a "Spike" column can help track these short-term investigations.

3. Encourage "Micro-Experiments" in Daily Work

Experimentation doesn't have to be reserved for dedicated spikes. Encourage engineers to build small tests into their everyday tasks.

  • A/B Testing: Even seemingly small UI changes can be A/B tested.
  • Refactoring Challenges: Instead of a massive refactor, break it down into smaller, testable chunks. Each chunk is an experiment to improve code quality.
  • “What If” Scenarios: Encourage engineers to explore alternative approaches to a problem, even if they don't implement them. “What if we used a different database?” “What if we migrated to a microservices architecture?”

The Long View: Building a Learning Organization​

Fostering experimentation isn't a one-time fix. It's about building a learning organization where curiosity is valued, and failure is seen as an opportunity for growth. We often forget, in our era of hyperspecialization, that meaningful innovation comes from exploration.

As Jørgensen and Sjøberg (2000) argue in their work on software development, actively learning from experience – rather than simply repeating established patterns – is crucial for continuous improvement.

Ultimately, encouraging experimentation isn't just about building better software. It's about building better engineers and a more innovative team.

Key Takeaways:

  • Normalize Failure: Implement blameless post-mortems and encourage sharing of learnings from failed experiments.
  • Embrace Spikes: Use time-boxed explorations to de-risk assumptions and gather data.
  • Integrate Experimentation: Encourage small, iterative experiments in daily work.

References:

Jørgensen, M., & Sjøberg, K. (2000). Learning from experience: A qualitative study of experienced software developers. IEEE Transactions on Software Engineering, 26(11), 1039–1055.